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The quality of the systems engineering and 
integration (SE&I) process determines the 
viability, effectiveness and the survivability 
of major NASA flight programs. In mission 
operations, SE&I is the process by which the 
technical, operational, economic and politi- 
cal aspects of programs are integrated to 
support the program objectives and require- 
ments consistent with sound engineering, 
design and operations management princi- 
ples. 

Major flight programs involve operation- 
al, cost, and political elements and priorities, 
international prerogatives, and often poorly 
focused utilization requirements, in addition 
to traditional technical trades, technology 
utilization, and interface definition and con- 
trol. This combination demands an effective 
SE&I process that spans and involves all 
these elements. 

SE&I, therefore, is a distributed process 
that involves the structuring and integrated 
management of a program within and be- 
tween the program, project and technical 
levels, with a life cycle consistent with the 
program phase. SE&I must anticipate pro- 
gram needs by providing clear technical 
assessments, trades and alternatives aimed 
at satisfying the program objectives and 
requirements. 

This paper will describe the key princi- 
ples and processes used within mission oper- 
ations, emphasizing the pre-mission prep- 
aration activities most useful for describing 
the principles of an effective SE&I process. 

Early development of Mission 
Operations 

The development of mission operations capa- 
bilities for manned space flight involved a 
rapid evolution from the traditional method 
of aircraft flight test operations used during 


the early Mercury program to the mature 
and structured process used for Apollo. The 
flight experience of the Mercury program re- 
vealed the need for a deeper knowledge of 
spacecraft systems by flight operations 
teams. It further indicated a need for 
systems documentation tailored to the opera- 
tor’s real-time task. By the completion of 
Mercury, a systems handbook had been 
developed as an “on-console,” real-time docu- 
ment for flight systems data. Direct commu- 
nication was established between the operat- 
ing team and the manufacturer so that any 
additional systems data needed during the 
course of the mission could be obtained. This 
communication also provided a means for 
getting engineering judgment on operational 
trades, whenever time permitted. The flight 
rules became the focus of operational poli- 
cies. 

The Gemini program required the devel- 
opment of the trajectory capabilities needed 
for rendezvous and docking, as well as a 
guided reentry capability. These require- 
ments established the linkage between tra- 
jectory; guidance, navigation and control 
(GNC) systems; and propulsive consumables. 
The Gemini extravehicular activity (EVA) 
increased awareness of the relationship be- 
tween crew, the task and the working envi- 
ronment. 

During Apollo, science became the final 
mission component supported by the oper- 
ations teams. The Apollo operations team 
worked in an integrated fashion on all issues 
involving flight systems, flight design, 
science and manned operations. 

It was during the Skylab program that 
the first formal and broad-scale application 
of the mission operations (SE&I) process 
emerged to support the early flight system 
hardware and software design. During the 
Skylab design reviews, many of the review 
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item discrepancies (RIDs) revealed the need 
for much closer relations between systems 
design and operational utilization. 

The multiple Skylab systems elements, 
combined with the broad spectrum of scienti- 
fic objectives and the complexity of manned 
and unmanned flight, required an early and 
effective relationship between flight systems 
designer, scientist-user and mission oper- 
ations. A Johnson Space Center (JSC) oper- 
ations team and a Marshall Space Flight 
Center (MSFC) engineering team joined to 
conduct a series of systems operations com- 
patibility assessment reviews (SOCARs). 
During these and all subsequent reviews, the 
Skylab systems and software handbooks pro- 
duced by mission operations were used as the 
baseline reference documentation for the 
SOCAR. These documents were also used by 
the JSC and MSFC teams for the flight phase 
of the program. Skylab real-time operations 
demonstrated the effectiveness of this rela- 
tionship between the JSC and MSFC teams. 

The mission operations team supported 
the design and development phase of the 
Space Shuttle program at the program and 
project levels and helped develop operational 
workarounds for flight systems and software 
deficiencies that could not be corrected be- 
fore the flight test phase of the program. 

Mission Operations Structure 

The Mission Operations Directorate (MOD) 
at the Johnson Space Center is highly inte- 
grated and structured around the principal 
skills needed for mission preparation, plan- 
ning, training, reconfiguration, facility de- 
velopment, facility operations and real-time 
flight operations. 

Each mission operations element consists 
of a single functional discipline, e.g., mission 
design, flight systems, reconfiguration, 
training, etc. Usually each organizational 
element is structured to provide dedicated 
support to either the Shuttle or Space Sta- 
tion. This is believed to be the best way for 
assuring accountability in individuals and 


management, avoiding conflicting priorities 
and providing leadership focus. The only 
exception is a Flight Design and Dynamics 
Division (FDDD), which provides integrated 
flight design for the Shuttle and all pro- 
grams using Shuttle services. 

Each division is responsible for integra- 
tion within its work area and provides 
mission operations representation to the 
project-level boards. Program-level boards 
are generally supported through the Flight 
Director Office, by the Operations Division 
and by the FDDD. Integration between pro- 
grams is accomplished by the MOD assistant 
directors for the Shuttle and for the Space 
Station. 

In addition to the internal integration 
process, each division generally has a hori- 
zontal integration responsibility that identi- 
fies, collects and documents the capabilities 
and constraints imposed by other elements. 
This integration process frequently incorpo- 
rates participants external to mission oper- 
ations (for example, participants from the 
program and the project), as well as the 
flight system contractor and the payload 
user. In most cases, this is accomplished by 
mission operations directed panels that are 
chartered by the program. 

Introduction to Mission Operations 

SE&I 

This paper will discuss three mission oper- 
ations functions that are illustrative of the 
key principles of operations SE&I and of the 
processes and products involved. 

• The flight systems process was selected to 
illustrate the role of the systems product 
line in developing the depth and cross- 
disciplinary skills needed for SE&I and 
providing the foundation for dialogue 
between participating elements. 

• FDDD was selected to illustrate the need 
for a structured process to assure that 
SE&I provides complete and accurate 
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results that consistently support program 
needs. 

• The flight director’s role in mission oper- 
ations was selected to illustrate the com- 
plexity of the risk/gain tradeoffs involved 
in the development of the flight tech- 
niques and flight rules process as well as 
the absolute importance of the leadership 
role in developing the technical, oper- 
ational, and political trades. 

Flight Systems Division SE&I 

The early Mercury program employed a mix- 
ture of operations and engineering personnel 
to support the real-time operations. Later, 
flight experience established the need for a 
full-time systems operations team. The need 
for an integrated compilation of flight sys- 
tem data usable by the crew and ground 
team for real-time operations led to early 
versions of the systems handbooks that are 
the foundation for today’s handbooks. Rudi- 
mentary integrated schematics were used for 
Gemini, but with the Apollo program came 
more complex inflight computing capability. 
Consequently, the schematics were expand- 
ed to define the computer interfaces and used 
significantly more of the vehicle design and 
performance data base within the schematic 
notes. 

As mentioned earlier, the schematics 
were used for the first time to support the 
Skylab critical design reviews and the 
SOCAR. During these reviews, program and 
project management recognized that the sys- 
tems operations teams and the systems 
handbooks were an SE&I asset. The modu- 
larity of the Skylab elements, along with the 
integrated nature of the systems, established 
the pre-mission role for the systems hand- 
books to support the flight system design 
review process as an integrated activity. The 
usefulness of the handbooks in addressing 
integrated systems issues was thus formally 
established. For the Apollo Soyuz Test Pro- 
gram (ASTP), and the Shuttle and Spacelab 
programs, the preliminary version of the 


mission operations schematics were complet- 
ed prior to the flight system critical design 
review (CDR) and were used as the founda- 
tion for the mission operations assessments. 

The Systems Handbook Today 

Mission operations schematics are developed 
by the controllers to a common set of internal 
drafting standards and conventions and use 
the design engineering drawings, vendor 
schematics and software source code. For the 
Shuttle, operations personnel were required 
to develop Houston Aerospace Language/ 
Shuttle software language skills as a job 
requirement. Permanent, prime contractor, 
in-house and in-plant support assures the 
flow of the raw design data and provides the 
communications conduit between the sys- 
tems operations personnel and the prime 
contractor design engineers so they can ad- 
dress questions as they arise. After the STS- 
51L accident, all handbook schematics were 
expanded to provide direct traceability to 
design drawings by title, drawing number, 
revision and date. 

The systems controllers who develop the 
schematics derive significant training from 
using design data and translating this data 
into an operationally useful format. The 
schematic development and the integration 
of data from supporting systems and subsys- 
tems provides independent validation of the 
system design intent. In particular, it identi- 
fies issues where the integrated design may 
have compromised the program intent. The 
drawing configuration control process re- 
quires verification by section and branch 
chiefs and final approval by the division 
chief. Formal reviews are conducted before 
major handbook releases. As a result, the op- 
erator and the supervisory chain derive a 
training benefit from the systems handbook 
process. 

The systems handbooks are used by 
crews, flight directors, training instructors 
and mission operations payload support per- 
sonnel. They are a formal portion of training 
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documentation and are carried in the Shuttle 
flight data file. The schematics support 
airborne system troubleshooting and provide 
a common base for the crew and the ground 
to discuss suspected problems and follow-on 
actions. They provide the basis for MOD dis- 
cussion with the contractor engineering 
team and with the mission support team. 

Flight Procedures. The development of the 
systems handbook provided the foundation 
for the development of flight procedures. 
Three basic categories of flight procedures 
are developed: the operations checklists, the 
pocket checklists and the malfunction proce- 
dures. 

The operations checklist procedures allow 
the crew and ground systems operations to 
accomplish a planned activity and are nor- 
mally developed as blocks of integrated sys- 
tems activities; for example, aligning the 
inertial measurement unit. Procedures de- 
velopment requires intimate familiarity 
with the system; its interfaces, controls, and 
displays; and with the intended task to be 
accomplished. Operations checklist proce- 
dures cross all systems and technical disci- 
plines, and as a result of their development, 
provide another level of systems integration 
and design validation. Procedures associated 
with an Orbital Maneuvering Subsystem 
burn, for example, involve loading the ma- 
neuver targets into the computer, selecting 
and configuring engines for the burn, acti- 
vating the correct digital autopilot, selecting 
displays, and specifying of data to be record- 
ed. 

Pocket checklists are emergency proce- 
dures based on the operations checklist. The 
term “pocket” is used because the checklists 
must be readily available for critical mission 
phases and are sized to be carried by the crew 
in the pockets of their flight suits. 

The pocket checklist procedures define 
the steps to be taken when an unplanned 
event occurs. These procedures address 
critical failures and are flight-phase unique. 
They require knowledge of system perfor- 


mance limits, crew capabilities, failure 
modes, and crew and ground response times. 
The emergency procedures therefore provide 
a bridge from operations checklist proce- 
dures into options that allow the crew to con- 
tinue the current flight phase with modifica- 
tion, to reconfigure to recover capabilities, or 
to utilize an alternate capability. Figure 1 is 
a typical procedure used during powered 
flight for a main B undervolt condition. 

The final type of flight procedures devel- 
oped by the controllers are the malfunction 
procedures (MALS), which are used when 
time is available to troubleshoot, locate and 
define the boundaries of problems that occur 
inflight. To solve the problem, the crew and 
ground use the full range of instrumentation 
available and any visual or external cues 
available. The procedures are developed in a 
logical format using a series of “if,” “and,” 
and “or” statements. Warning notes are pro- 
vided, as well as permissive steps when 
ground and crew consultation is required pri- 
or to continuing the procedural sequence. 
These procedures have allowed the correct 
isolation of the majority of inflight problems 
for the Shuttle program. 

A final category of flight procedures con- 
cern payload operations and involve multiple 
flight elements. 

Flight Systems Organizations. Since 
Gemini, the MOD flight systems organiza- 
tions have been structured to address a 
complete space system. Examples include 
command service module, lunar module and 
Shuttle. Each section within an organization 
has responsibility for an assigned system, 
with its subsystems, software, instrumen- 
tation, display, crew controls, command 
controls, procedures, mechanical, power, 
cooling, and thermal and consumable inter- 
faces. During the Skylab program, each or- 
ganization also had to know about inflight 
maintenance and support logistics. 

The systems organizations of the MOD 
participate in flight systems design via for- 
mal membership on the working groups, 
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panels and boards established by the pro- 
gram office. During the early design phase, 
they establish the data base for the develop- 
ment of schematics and procedures for the 
flight controllers. Because of this, direct con- 
tractor liaison is maintained within the 
MOD systems organization and in-plant. 

Development of the mission product line 
by the systems flight controllers increases 
their skills and knowledge. In addition, the 
product line focuses the operations assess- 
ments of overall flight system architecture 
and provides the foundation for subsequent 
steps. Finally, as a recognized product, it is 
used by several groups in support of their 
individual responsibilities. Program SE&I 
products typically must exhibit the same 
characteristics — they must pass the value- 
added test. 

The systems operations contribution to 
the early design and eventual operation of 
the flight system has been essential in assur- 
ing safe, effective and functional system 


capability for space flight. The perspective of 
the systems operator provides the cross- 
disciplinary assessment needed to assure ef- 
fective overall systems engineering and 
integration. This perspective is the corner- 
stone of the real-time capability of the man- 
ned spaceflight operations team. 

Flight Design Division SE&I 

The flight design process involves the inte- 
gration of payload and engineering require- 
ments with mission objectives to form an 
integrated mission design. The flight design 
must satisfy both Shuttle system design and 
payload design constraints while considering 
the additional constraints imposed in consid- 
eration of safe mission conduct and mission 
success. 

The flight design process is a critical node 
in the Shuttle mission preparation process. 
In addition to flight design, the process 
provides initialization data for the ground 
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Figure 2 Flight Design Template 


facilities, Shuttle primary and backup soft- 
ware, flight and payload planning, and real- 
time decision support products. 

Within the flight design and dynamics 
discipline there are three mission phase ana- 
lysis and design work areas — ascent, orbit 
and descent — and one functional area — real- 
time operations. The FDD, working in 
coordination with other mission operations 
elements, establishes and integrates the 
propulsive and non-propulsive consumables, 
abort propellant dump analysis, and manip- 
ulator requirements and analysis into the 
overall flight design. The overall integration 
of activities supporting a mission is provided 
by a flight design manager. 


The flight design process acquires a vast 
amount of input data from a wide variety of 
sources. The input data for the early phase of 
the program is typical specification data, but 
during the operational phase of the program 
it becomes highly flight specific and fre- 
quently component specific. A good example 
would be constraints for engine throttling 
related to a specific Space Shuttle Main 
Engine turbo pump. 

Flight Design Cycles. The flight design 
process has three principal cycles designed to 
satisfy the requirements and lead times of 
the many users. The conceptual flight profile 
cycle provides the program office with data 
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for making commitments to the payload 
customers and assessing the overall suitabil- 
ity of the operations flight design approach. 

The engineering cycle supports the ini- 
tialization of the engineering and test facili- 
ties as well as the initial shuttle mission 
simulator (SMS) training load. The flight 
cycle supports MCC and SMS initialization 
for final training and operations, Kennedy 
Space Center (KSC) Launch Processing 
System checkout and launch support, God- 
dard Space Flight Center network support, 
and range safety. The flight design cycles are 
under review to determine if a single cycle 
could be used to satisfy all user require- 
ments. This latter objective requires signifi- 
cant standardization within the program, 
improved and timely provision of payload 
specific data and significant training stan- 
dardization. 

Flight Design Documentation. The flight 
design process is the last of the mission oper- 
ations processes to be documented as a 
structured flow from the conceptual phase 
through the delivery of the launch-loads 
used for flight. The full documentation of 
these processes is now contained in 22 vol- 
umes of flight design handbooks. Documen- 
tation was undertaken to serve four distinct 
objectives: (1) document the corporate mem- 
ory of this process before it is lost; (2) estab- 
lish an error- and omission-free process, 
necessary because of the critical nature and 
use of the flight design products; (3) support 
the design of an integrated computing sys- 
tem as an aid to support the flight design 
process; and (4) assure consistent design and 
rationale between similar missions. 

The two years after the STS-51L accident 
were used to safe the flight design system, 
document the process and initiate a multi- 
year plan for code conversion, consolidation, 
documentation and configuration control of 
all applications software. Process flow charts 
were developed for every activity involved in 
the flight design analysis and production 
activity. 


The flight design handbooks developed 
during recent years have documented the 
flight design SE&I process and, to a great 
extent, represent the structure and relation- 
ships that must exist to incorporate integrat- 
ed trajectory design into any space program. 
These documents are invaluable examples of 
the structure and approach needed for fur- 
ther space exploration activity. They also 
provide a good textbook for personnel in- 
volved in SE&I management to describe the 
relation between trajectory, systems, soft- 
ware and objective data. In addition, they 
define input/output requirements, integra- 
tion nodes, audit points and interfaces to 
external elements for data acquisition and 
transfer. 

An Illustration of the Flight Design Pro- 
cess. The integration of the constraints im- 
posed by the flight system, environment, 
payload and operations in the determination 
of the launch window will be used to illus- 
trate one aspect of the flight design process. 

The launch window is the time period 
that the Shuttle should launch to achieve 
precise program requirements. This activity 
is described in the flight design handbook via 
three processes that satisfy Shuttle and 
payload requirements. These processes are 
further combined and iterated to develop the 
integrated launch window. This initial step 
of the process provides input data for subse- 
quent planning involving deorbit opportuni- 
ties, sequence of events, pointing, thermal 
assessments and so forth. 

The constraints imposed in launch win- 
dow determination represent the broad 
range of considerations faced by the flight 
designer in this task. Where practicable, 
priorities are established to assist the flight 
designer. The actual development of the 
launch window analyses is governed by a 27- 
page procedure within the flight design 
handbook. 

Flight design is an essential element for 
space flight. The documentation of this pro- 
cess captured what was in the minds of the 
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talented and imaginative individuals work- 
ing in this field, and provided the definitive 
text for future flight design work for space 
exploration. 

For the Space Station Freedom program, 
MOD has developed process flow charts for 
all functions that describe the input/output 
activities within mission operations and be- 
tween mission operations and the Level II 
program elements, MSFC, KSC, GSFC and 
international partners. These flow charts de- 
scribed interfaces, product exchanges and 
work templates. They were used to define the 
roles and mission boundaries needed for sus- 
tained and effective relationships between 
participants. Documentation of the SE&I 
process is absolutely essential to clear and 
effective role and responsibility definition, 
and is a primary step in minimizing jurisdic- 
tional battles between SE&I elements. 

Flight Directors SE&I 

The mission operations SE&I process uses 
the Flight Director Office to provide the top 
level, multidisciplinary integration, risk/ 
gain assessment and validation of the inte- 
grated mission preparation. 

Flight directors are selected from the 
ranks of MOD personnel. Selection is based 
on leadership, technical abilities, stability 
and judgment as established by their perfor- 
mance during flight operations. They are 
already intimately familiar with the operat- 
ing disciplines, interfaces, flight and ground 
systems capabilities, crew capabilities and 
the mission risk/gain process. The challenge 
for the flight directors is acquiring and 
maintaining the clear perspective needed for 
multidisciplinary technical, operational and 
political trades and leading the many di- 
verse elements to operationally correct risk/ 
gain decisions. 

The lead flight director is central to the 
process for the assigned missions. 

Pre-CDR Support. Support to a program 
from the Flight Director Office is initiated 


between the preliminary design reviews 
(PDRs) and CDRs. This phase is character- 
ized by major tradeoffs between program 
requirements, flight system design, crew and 
ground and customer roles, schedule and 
cost. During this period the flight director, 
supported by all mission operations ele- 
ments, refines the operating concepts and 
leads the operational trades involving auton- 
omy, fault tolerance, crew and ground func- 
tions, and flight design and payload suppor- 
tability. As flight system design becomes 
more focused during this period, the program 
costs and the real world design trades con- 
verge and program tradeoffs must be imple- 
mented. As a result, the mission operations 
integration process is initiated to provide the 
program and project managers with a clear 
understanding of available options. The op- 
tions are generally provided by in the form of 
operations compatibility studies, similar to 
the SOCARs described previously, or in the 
form of an integrated mission design assess- 
ment. 

CDR Support. The CDR support to the 
program from the mission operations team is 
significantly different because of the avail- 
ability of the mission operations flight 
systems handbooks and the increased knowl- 
edge of the team. The operations team has 
acquired significant experience in working 
with the program and project as a member of 
the change control board (CCB) and through 
the CCB processes. The CDR represents a 
milestone for reassessing the design and is 
frequently the first time that the maturity of 
the software begins to approach the maturity 
of the hardware. 

The principal contribution from mission 
operations during this time is in the detailed 
operational suitability assessments. These 
assessments concern the mission suitability 
of the flight system design and involve pro- 
gram requirements, hardware and software 
design, mission design, and crew and ground 
capabilities. Through these assessments the 
preliminary risk/gain trades and fault down 
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options are established, operating philos- 
ophies are defined and mission options ascer- 
tained. Within mission operations, the CDR 
is not a discrete process. It is considered one 
of the many milestones of a process charac- 
terized by an increasing involvement by 
operations personnel in the change boards 
and control mechanisms established by the 
program. The involvement extends to the 
flight preparation period, which has two dis- 
tinct processes and products representative 
of the flight director’s role in the mission 
operations SE&I. These processes involve 
flight techniques and flight rules. 

Flight Techniques. The initial flight tech- 
niques process was developed, and since 
Apollo, has been chartered by the Level II 
program. The process was established to 
address the growing complexity of the inter- 
action between flight software, flight system 
and flight objectives. This process provided 
the technical focus for the operations, engi- 
neering and contractor teams to address the 
use of the as-built flight system, the soft- 
ware, and the crew and ground capabilities 
in accomplishing flight objectives. During 
Apollo, the ground system, flight procedures 
and flight software were the only elements 
that could be readily changed within cost 
and schedule considerations. The flight tech- 
niques process, assisted by Draper Laborato- 
ries and the operational vehicle and software 
developers, established virtually all of the 
navigation capabilities for Apollo. They 
developed the technique for the Apollo 12 
pinpoint landing and were a principal contri- 
butor to the Apollo 13 return. 

The product line of the techniques process 
is initially the series of detailed meeting 
minutes, which provide the basis for flight 
procedures and the rationale for the majority 
of the flight rules and mission design con- 
straints. The flight techniques process pro- 
vides the integration of the knowledge base 
available on the flight system to drive flight 
designs, procedures and flight rules. 


Flight Rules. Flight rules are the funda- 
mental risk/gain policy document for mis- 
sion conduct. The “flight rules outline 
preplanned decisions to minimize the 
amount of real-time rationalization required 
when non-nominal situations occur from the 
start of the terminal countdown through 
crew egress.” 

The most complex, difficult and critical of 
the integration processes provided by the 
Flight Director Office is flight rules develop- 
ment. Flight rules used today trace their 
beginnings to aircraft flight tests. Rudimen- 
tary guidelines were provided for the flight 
test pilots relative to test conditions, and go- 
no-go criteria were provided for test continu- 
ation or termination. Similarly, during 
Mercury the rules for selected systems fail- 
ures were also a simple set of go-no-go crite- 
ria involving powered flight abort and 
mission continuation or termination. Rules 
also addressed the control center, network 
and flight instrumentation requirements. 
Today’s flight rules involve sophisticated 
risk/gain trades across redundant systems, 
multiple mission phases, engineering and 
payload objectives, and crew and controller 
capabilities. They also reflect and tradeoff 
the payload objectives, crew adaptation and 
flight system survivability in defining mis- 
sion duration for off-normal conditions. 
Additionally, they clearly define the respon- 
sibilities of key personnel implementing 
flight operations. 

While the rules are infinitely more com- 
plex, the principle of the rules remains the 
same; that is, “to establish the risk versus 
gain trades” before the mission, utilizing the 
full range of operational, program and engi- 
neering judgment available in the pre- 
mission environment. 

To assure complete visibility to all trade- 
offs involved in the flight rules, rule ratio- 
nale, techniques data and Systems Oper- 
ations Data Book (SODB), references are 
contained in the published rules. The SODB 
and its variants were developed during 
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Figure 3 Mission Operations Integration 


Gemini by mission operators with support by 
the prime contractor for the purpose of docu- 
menting the performance capabilities and 
limitations of the flight system. Since 
Apollo, the SODB has been maintained by 
the prime contractor, with mission oper- 
ations as the primary user. 

The leadership function provided by the 
flight director, using the flight techniques 
and flight rules process, provides the focus 
for the integration of flight-specific work 
within mission operations. 

The rules and rationale section in the all- 
flights document is almost 900 pages. The 
flight-specific annex published for each 
mission is about 70 pages. It is provided to 


address the flight-unique objective and 
payload risk/gain trades for each specific 
mission, flight objective and payload ele- 
ment. 

Flight directors, like program and project 
managers, depend on a matrix structure of 
organizations to accomplish their responsi- 
bilities. The flight directors are consistently 
successful because their roles are well 
defined, and because the integration tech- 
niques are facilitated by the MOD organiza- 
tion structure as well as by clearly defined 
product line and support processes. These 
characteristics must exist to successfully 
cope with the complex issues imposed by all 
mission elements. 
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Principal Requirements of an 
Effective SE&I Process 

The mission operations elements, processes, 
and products are oriented to the singular ob- 
jective of safe and successful manned flight 
operations. The spacecraft on the drawing 
board, like the ship in a harbor, is a safe 
ship, but that is not what spacecraft and 
ships are for. The mission operations job is to 
take the spacecraft from the harbor of the 
drawing board into space, accomplish a mis- 
sion and then safely return the spacecraft to 
Earth. 

In recognition of this responsibility, the 
mission operations processes are structured 
to assure effective policy, objective, system 
and operations integration. Within this 
framework, complex risk/gain trades are 
conducted and validated at all levels, culmi- 
nating in a completely independent and 
dynamic assessment and stress test during 
the integrated training process. 

The mission operations process can illus- 
trate the principles necessary to a successful 
SE&I. It is believed that these principles are 
useful to other SE&I elements that have the 
responsibility for NASA flight programs at 
the project and program level. 

1. SE&I must have necessary roles and 
missions that are clearly defined by the pro- 
gram and implemented by the project and 
technical organizations. 

SE&I is necessary because the integra- 
tion processes needed to address the techni- 
cal, operational, political and economic 
aspects of major programs are complex. 

The value-added principle is the basic 
test that should be used in determining role 
and mission assignments. 

SE&I by its nature will be controversial 
and participating elements may stonewall 
the process. When this occurs, the program, 
project or technical manager must quickly 
and personally address the issue, establish a 
program position and demand the support 
required. 


2. SE&I must utilize the existing capabil- 
ities of organizations. 

SE&I is the “integration” of the techni- 
cal, operational, economic and political as- 
pects needed to support a major program. 
The broad range of work, skills required and 
complexity of issues virtually precludes the 
development of a single SE&I organization 
for a major program. SE&I responsibility 
must be distributed to be successful. 

3. SE&I elements must recognize and ac- 
cept that major and complex programs will 
involve technical, operational, political and 
economic needs. 

Major programs must address and sup- 
port the needs of the various constituencies 
involved in establishing the program and 
must consider all of the economic issues 
involved in program development and 
operations. This recognition is essential if 
NASA and its contractors are to develop a 
more flexible and responsive approach to 
program management. 

4. SE&I must have a process-based struc- 
ture and a defined product line and life cycle. 

The complexity of SE&I requires a struc- 
tured process to assure all interfaces are ad- 
dressed, proper responsibilities assigned, 
and SE&I is effectively mechanized. SE&I 
requires a solid grasp of all the elements to 
be brought together, where the elements 
logically come from, where they fit in the 
sequence, what the end product is and what 
the alternatives are. 

SE&I can be accomplished by a few gifted 
people for a limited time, but without 
structured processes, SE&I will become 
inefficient, outputs will not meet schedule 
commitments, “more integration resources 
will be needed, and the downward spiral will 
begin.” SE&I is not provided by massive ap- 
plication of resources. It comes about by 
structured processes that clearly establish 
the roles and responsibilities of the support- 
ing elements and use them effectively. 

The SE&I process definition is also used 
to establish the product line of participating 
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elements and define input/output require- 
ments. This product line must be phased to 
the life cycle of the program. 

5. SE&I leadership must exist within all 
elements of the SE&I process structure and 
must be clearly recognized and accepted by 
the assigned individuals and their organiza- 
tions. 

Accepting an SE&I leadership role is to 
recognize and accept conflict, particularly in 
the project and technical organizations. 
Organizations assigned an SE&I role must 
recognize and accept the technical, oper- 
ational, political and economic implications 
of the SE&I role. SE&I must address the 
needs of the program, which must supersede 
the needs of individuals and organizations. 


SE&I within NASA’s flight programs is a 
constantly evolving and complex process 
involving many conflicting requirements 
that must be brought together to support 
program needs throughout the program’s life 
cycle. An SE&I process that is effectively 
structured with distributed responsibilities 
will support program needs and recognize 
many of the prerogatives of the existing 
NASA elements. Each complex program, 
however, will have some elements that do 
not fit neatly into the existing NASA 
infrastructure because of economic, political 
or other considerations. SE&I will always be 
controversial, in structure and in implemen- 
tation. 
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